home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 558 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.5 KB
  1. Subject: Re: pipes & ptys 
  2. Date: Mon, 18 Oct 93 15:36:50 MDT
  3. From: Howard Chu <hyc@hanauma.jpl.nasa.gov>
  4.  
  5.  
  6.   > But if I open a pipe as a pseudo tty and use 1 Bytes reads/writes - which
  7.   > looks normal for shell i/o to me
  8.   
  9.    hmm user processes doing 1 byte read()/write()s _is_ slow. :(  system
  10.   calls are expensive...  (and also the library adds its share too...)
  11.  
  12. A simple shell would just use cooked mode and read a line at a time, not
  13. single-character, btw...
  14.   
  15.    not sure how much can be done about 1-byte IO (i fear the library
  16.   and system call overhead are the biggest part already...)  i think the
  17.   first thing to do would be change gnulib and all your other programs
  18.   that still do it to avoid 1-byte IO where possible. (might need a few
  19.   if (__mint) and Fcntls on ttys but the result should be worth it...)
  20.   and then improve tty.c&friends so that long read/writes can get _really_
  21.   efficient.  currently the problem is they do a lot of device-level
  22.   1-char IO and shuffling bytes into 32-bit `chars' and back... i.e. when a
  23.   pty slave writes 1k that gets expanded into 4k, and when the master then
  24.   does a 1k read its collapsed again.  and whats worse pipefs' read then
  25.   gets called a 1000 times!  instead of once.  that is what makes ptys
  26.   slow... (and serial ports too, but i said that before. :)
  27.  
  28. (Just a note to TeSche - the 1 byte I/Os are converted to 4 bytes to allow
  29. pty's to pass scan code and shift status info, just like Bconin from console.)
  30.   
  31.    now how fix this (i mean _really_ fix this. so that a 1k read ends up
  32.   as one 1k device read whenever possible, without additional moving data
  33.   around) and stay compatible with existing devices?  here is an idea...
  34.   
  35.   1. add 2 optional functions to DEVDRV struct, for now i call them bread
  36.   and bwrite. (NULL means they are not there)  they work like device read
  37.   and write, only with bytes instead of longs.  (btw there are 3 longs
  38.   reserved in DEVDRV now and i can think of atleast 2 more functions to
  39.   add later, readv and writev...  so extend the struct somehow?)
  40.   
  41.   2. if bwrite is there use it instead of write in tty_write (also in
  42.   bflush, midiws...), if the write is RAW just check for job control and
  43.   return (*f->dev->bwrite)(f, buf, nbytes);
  44.    and if bread is there do the same atleast for RAW reads in tty_read.
  45.   (this includes reading pty masters...)
  46.   
  47.   3. add bread and bwrite functions to the pty device.  the slaves output
  48.   pipe can then be changed to use bytes directly. (i think.  the other
  49.   direction of course not...)
  50.   
  51.   4. add support for CLOCAL, HUPCL, VMIN etc and make _real_ modem devices...
  52.   with bread/bwrite they finally could get decent thruput without 99% CPU load.
  53.  
  54. ...and CTLECHO, I guess we want full termio(s) support, eh?
  55.   
  56.    this is just an idea i got and i have no idea if and when i could do
  57.   all this... :)  but what do you think?
  58.  
  59. I kind of like it. The main point being, we want a system call that actually
  60. reads or writes more than 1 byte at a time for ttys. So doing an Fread of 1K
  61. on /dev/modem1 does a single call, not 1000 Bconin's... I would like to see
  62. these new read and write functions replace Bconin/Bconout, with Bcon* just
  63. being a special-case (single-character) of them.
  64.  
  65. I would suggest that a better way to handle this would be to continue
  66. supporting the 4 bytes per character, but have an additional flag bit which
  67. indicates whether or not the caller is interested in the 3 extra bytes. If not,
  68. just perform the data copy by incrementing the pointer by 4 instead of by 1...
  69.